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SYSTEM AND METHOD FOR DATA TRACKING AND MANAGEMENT 

RELATED APPLICATION 
The present application claims a right of priority 
under 35 U.S.C. §119 to U.S. provisional patent application 
5 entitled tt INFORMATION TRACKING SYSTEM," filed January 18, 
2002 and having Serial No. 60/349,914, the disclosure of 
which application is hereby incorporated by reference. 

BACKGROUND OF THE INVENTION 
1 . Field of the Invention 
10 The present invention relates to systems and methods 

for tracking and managing the flow of data in a computer 
network . 

2 . Description of Related Art 

The growth in e-business, along with trends in mergers 

15 and acquisitions, has introduced new challenges for 

businesses. As organizations' networks of applications, 
business units and users become more complex and 
fragmented, better tools are needed to ensure that the data 
is secure, accurate, and readily accessible. There is a 

20 need to ensure smooth collaborations with new enterprise 
and e-business applications. In summary, in addition to 
retaining investments in legacy systems, there are also 
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growing needs to address information security, privacy and 
to ensure end-to-end data transmission integrity across an 
enterprise by providing insight to the health and 
performance of the enterprise. 
5 Currently, a typical enterprise network is built 

around a large enterprise solution wedded to one or more 
legacy systems. While conventional enterprise application 
integration and system network monitors perform an adequate 
job of tracking and managing data within their own system, 

10 these networks typically are unable to track data flow 
outside their system. Many times, however, a complete 
business process will pass data outside of the enterprise 
solution to a legacy system. 

To get a full visualization of information movement 

15 over a network, conventional data tracking systems 

collected data on information activities from various audit 
trails such as log files and event files. Typical systems 
then required manually analyzing the data and producing a 
subsequent report. Conventional systems are also 

20 restricted to using pre-defined rules in data movement to 
detect possible internal breaches. It is desirable, 
therefore, to track the data flow throughout the complete 
business process across the entire enterprise. It is 
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further desirable to provide a data tracking system that 
can ensure complete end-to-end data integrity across 
multiple platforms. 

BRIEF SUMMARY OF THE INVENTION 
5 In one embodiment of the present invention, a system 

for tracking and managing data over a computer network 
including a plurality of application computers each 
operating a computer software application program is 
provided, comprising a key master; a system startup module 

10 connected to the key master; a gatekeeper connected to the 
system startup module; a task manager connected to the key 
master and the gatekeeper; a central database connected to 
the gatekeeper; a plurality of agents connected to the task 
manager; a plurality of sub- agents independently connected 

15 to the plurality of agents and the plurality of application 
computers; and an alert dispatcher connected to the system 
startup module and the gatekeeper. 

In this embodiment, the alert dispatcher provides an 
alert notification comprising an email message, an 

20 electronic instant message, and/or a paging message. In 
this embodiment, the system uses a Linux operating system 
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and the central database comprises a plurality of 
independent databases . 

In another embodiment of the present invention, a 
method for tracking and managing a message over a computer 
5 network including a plurality of application computers each 
operating an computer software application program is 
provided, comprising the steps of monitoring the message at 
a lowest common format; comparing content of the message to 
a validator key; extracting a message key if the content of 
10 the message matches the validator key; assembling the 
message according to one or more predetermined rules; 
queuing the message; retrieving the message; and storing 
the message. 

In this embodiment, the method further comprises the 
15 step of alerting an operator with an alert notification of 

a shutdown of the one of the plurality of application 

computers. In this embodiment, the alert notification 

comprises an email message, an electronic instant message, 

and/or a paging message. 
2 0 In this embodiment, the method further comprises the 

steps of retrieving the message; and viewing the message. 

In one embodiment, the lowest common format comprises 

TCP/IP, FTP, or SNA. 
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In a further embodiment, a method for tracking and 
managing a message over a computer network including a 
plurality of application computers each operating a 
computer software application program is provided, 
5 comprising the steps of monitoring content of the message 
with a sub-agent; comparing the content of the message to a 
validator key with the sub-agent; extracting a message key 
if the content of the message matches the validator key 
with an agent; assembling the message based on one or more 
10 predetermined rules; queuing the message; retrieving the 
message with a task manager; and storing the message in a 
central database . 

In this embodiment, the method further comprises the 
step of alerting an operator with an alert notification of 
15 a shutdown of the one of the plurality of application 
computers. In this embodiment, the alert comprises an 
email message, an electronic instant message, and/or a 
paging message . 

In an embodiment, the central database comprises a 
20 plurality of independent databases. In an embodiment, the 
method further comprises the steps of retrieving and 
analyzing the message. In one embodiment, the lowest 
common format comprises TCP/IP, FTP, or SNA. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 shows a block diagram of the data tracking and 
management system in an embodiment of the present 
invention. 

5 FIG. 2 shows a hardware configuration of the data 

tracking and management system in an embodiment of the 
system. 

FIG. 3 shows a communications protocol of the data 
tracking and management system in an embodiment of the 
10 invention. 

FIG. 4 shows a communications protocol between a Task 
Manager and a Gatekeeper of the data tracking and 
management system in an embodiment of the invention. 

FIG. 5 shows a communications protocol between a Key 
15 Master and a Gatekeeper of the data tracking and management 
system in an embodiment of the invention. 

FIG. 6 shows a communications protocol between an 
Alert Dispatcher and a Gatekeeper of the data tracking and 
management system in an embodiment of the invention. 
2 0 FIG. 7 shows a communications protocol between an 

Agent and a Sub-Agent of the data tracking and management 
system in an embodiment of the invention. 
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FIG. 8 shows a diagram illustration a shutdown 
procedure for a Task Manager of the data tracking and 
management system in an embodiment of the invention. 

FIG. 9 shows a diagram illustrating a shutdown 
5 procedure for a plurality of Task Managers of the data 
tracking and management system in an embodiment of the 
present invention. 

FIG. 10 shows a diagram illustrating a shutdown 
procedure for a Key Master of the data tracking and 
10 management system in an embodiment of the invention. 

FIG. 11 shows a diagram illustrating a shutdown 
procedure for a Gatekeeper in an embodiment of the 
invention. 

FIG. 12 shows a diagram illustrating a shutdown 
15 procedure for an Alert Dispatcher in an embodiment of the 
invention. 

DETAILED DESCRIPTION OF THE INVENTION 
FIG. 1 shows a block diagram of the Data Tracking and 
Management System in an embodiment of the present 
20 invention. In this embodiment shown in FIG. 1, the Data 

Tracking and Management System 2 comprises a System Startup 
Module 100 , a Gatekeeper 102 , an Alert Dispatcher 104, Key 
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Masters 106 and 108, a Viewer 110, Central Database 112, 
114 and 116, Task Managers 122, 124, 126, 128 and 130, 
Agents 132, 134, 136, 138 and 140, and Sub-Agents 142, 144, 
14 6, 148 and 150. In this embodiment, the System Startup 
5 Module 100 is connected to the Gatekeeper 102, the Alert 
Dispatcher 104, and the Key Masters 106 and 108. The 
Gatekeeper 102 and the Viewer 110 are further connected to 
the Central Databases 112, 114 and 116. The Gatekeeper 102 
is also connected to Alert Dispatcher 104. The Key Masters 
10 106 and 108 are further connected to the Task Managers 122, 
124, 126, 128 and 136. In this embodiment, the Key Master 
106 is connected to the Task Managers 122, 124, and 126 and 
the Key Master 108 is connected to the Task Managers 12 8 
and 130. 

15 In this embodiment, the Task Manager 122 is connected 

to the Agents 134, 136, 138 and 140, while the Task Manager 
124 is connected to the Agents 132, 136 and 140. The Task 
Managers 126, 128, and 130 can be connected to the one or 
more Agents 132, 134, 136, 138 and 140, but for clarity 

20 sake are not shown in the FIG. 1. It is also noted that in 
various embodiments, not every Task Manager is logically 
connected to every Agent, and that two or more Task 
Managers can be logically connected to the same Agent . 

8 
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Each of the Agents 132, 134, 136 , 138 and 140 are also 
connected to each of the Sub-Agents 142, 144, 146, 14 8 and 
150, respectively. I another embodiment, more than one of 
the Agents 132, 134, 136, 138 and 140 can be connected to 
5 one of the Sub-Agents 142, 144, 14 6, 148. Each of the Sub- 
Agents 142, 144, 146, 148 and 150, is further connected to 
an application machine 152, 154, 156, 158 and 160, 
respectively . 

In this embodiment, each of the connections described 
10 above can comprise a physical connection such as a cable 
using an Ethernet protocol. Also, the connection can 
further comprise an Ethernet switch and router if the two 
endpoints of the connection reside on different physical 
computers. In another embodiment, the connections can 
15 comprise a virtual connection using techniques such as 
system calls or inter-process communications if the two 
endpoints of the connection reside on the same physical 
machine. Alternatively, if the two endpoints of a 
connection reside on the same machine, the virtual 
2 0 connection can use an Ethernet protocol along with a 
conventional loopback device. 
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In this embodiment, the System Startup Module 100 
comprises a script or program that initiates other 
components of the system, including the Gatekeeper 102, the 
Alert Dispatcher 104, and the Key Masters 106 and 108. In 
5 one embodiment, the Gatekeeper 102, the Alert Dispatcher 
104, and the System Startup Module 100 all reside on a 
single computer using a UNIX operating system. In such an 
embodiment, the System Startup Module 100 initiates the 
Gatekeeper 102 and the Alert Dispatcher 104 using a 
10 conventional system call such as M exec w , "system", or 

"fork", which is a method for one process to start another. 
In this embodiment, the Key Masters 106 and 108 reside on 
other computers and can be initiated using a remote 
invocation, such as the use of "rsh" , u remsh" or "rexec" on 
15 a computer using UNIX, or the use of remote invocation 
methods on a computer using a Java Virtual Machine. In 
alternative embodiments, one or more of the Key Masters can 
reside on the same machine as the System Startup Module 
100. In this case, the one or more Key Masters can be 
20 launched with a single system call. In other embodiments, 
the Gatekeeper 102 and/or the Alert Dispatcher 104 can 
reside on separate computers than the System Startup Module 
100 and can be initiated using a remote invocation. 
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Additionally, a remote invocation can be used even if the 
components reside on the same computer by applying the 
invocation over a loopback device. 

In an embodiment, the Gatekeeper 102 services requests 
5 and responses to and from one or more of the Central 

Databases 112, 114 and 116, serving as a buffer between the 
Central Databases 112, 114 and 116 and the various Task 
Managers 122, 124, 126, 128 and 130. In some embodiments, 
the Gatekeeper 102 also serves as a buffer between the 
10 Central Databases 112, 114 and 116 and the Alert Dispatcher 
104. In operation, the Gatekeeper 102 pools database 
transactions to more efficiently transfer data to and from 
the Central Databases 112, 114 and 116. In addition, the 
Gatekeeper 102 functions as an intermediary by which the 
15 Viewer 110 configures the Task Managers 122, 124, 126, 128 
and 130 and the Agents 132, 134, 136, 138 and 140 by 
delivering configuration parameters to the Task Managers 
122, 124, 126, 128 and 130. Through the responsible Key 
Master, the online status of a Task Manager 122, 124, 126, 
20 128 and 130 can be altered by relaunching or terminating 
that Task Manager as specified by the Viewer 110. For 
example, the Viewer 110 can request termination of Task 
Manager 128 by sending a request to the Gatekeeper 102, 
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which then issues a request to the responsible Key Master 
108 • Finally, the Key Master 108 terminates the Task 
Manager 128. The Gatekeeper 102 can further update the 
Central Databases 112, 114 and 116 regarding status or 
5 errors that occur during these configuration or alerting 
processes . 

In an embodiment, the Alert Dispatcher 104 queries or 
polls one or more Central Databases 112, 114 and 116 at 
predetermined periodic intervals for alert situations. In 

10 an alternate embodiment, the Central Databases 112, 114 and 
116 can directly notify the Alert Dispatcher 104. In other 
embodiments, for the polling transaction or the 
notification transaction described above, the Gatekeeper 
102 can be employed as an intermediary. If the Alert 

15 Dispatcher 104 detects an alert situation or is notified of 
an alert situation, it sends out alerts to one or more 
relevant administrators using one or more predefined alert 
methods. As shown in FIG. 1, these alert methods can 
include email 118, instant messaging 119 and/or paging 120. 

2 0 In one embodiment, the nature of the alert determines 

the alert method and relevant administrators. For example, 
a system administrator is paged in the event that a system 
failure is detected. In another example, an application 
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user is emailed when an error occurs in that specific 
application, but not when an alert situation develops 
related to another application. In another embodiment, the 
lack of an alert situation constitutes an alert situation, 
5 so an administrator is periodically notified that the 

system is operating properly. In another embodiment, the 
Alert Dispatcher 104 is configured to defer non-critical 
alert situations until an appropriate time, such as during 
regular business hours. 
10 In one embodiment, the Alert Dispatcher 104 queries or 

polls the Central Databases 112, 114 and 116 for various 
data based on the configuration parameters, and then 
determines whether an alert is warranted. For instance, the 
Alert Dispatcher 104 can include a parameter for a maximum 
15 connection timeout. If a connection is inoperable for at 

least that time interval, the Alert Dispatcher 104 provides 
an alert to an appropriate party. 

The Key Masters 106 and 108 manage the online state of 
one or more of the Task Managers 122, 124, 12 6, 12 8 and 
20 130. The Key Masters 106 and 108 are also responsible for 
the launching of each Task Manager 122, 124, 126, 128 and 
130 it manages and the relaunching of any Task Manager 122, 
124, 126, 128 and 130 it manages that may have terminated. 

13 
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In the embodiment shown in FIG. 1, the Key Master 106 is 
responsible for managing the Task Managers 122, 124, 126 
and the Key Master 108 is responsible for managing the Task 
Managers 128 and 130. When the online state of a Task 
5 Manager 122, 124, 126, 128 and 130 needs to be changed, the 
responsible Key Master 106 and 108 is notified by the 
Gatekeeper 102 of the required change. If a particular 
Task Manager 106 and 108 terminates abnormally, the 
responsible Key Master 122, 124, 126, 128 and 13 0 detects 
10 the online status change and relaunches that Task Manager. 
If a particular Task Manager 122, 124, 126, 128 and 130 is 
to be terminated, the Key Master 106 and 108 terminates the 
Task Manager upon notification by the Gatekeeper 102. 

In one example, a Key Master 106 and 108 operates on 
15 the same computer as the certain Task Managers 122, 124, 
126, 128 and 130. Hence, the Key Master 106 and 108 can 
launch or relaunch the Task Manager 122, 124, 126, 128 and 
13 0 using a system execute call, such as the use of "fork". 
The Key Master 106 and 108 can terminate a Task Manager 
20 122, 124, 126, 128 and 130 using a system termination 

command such as "kill". in another embodiment, two or more 
of the Task Managers 122, 124, 126, 128 and 130 reside on 
different machines and a remote invocation can be used to 

14 
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launch or terminate the Task Managers 122, 124, 126, 128 
and 13 0. 

In this embodiment, the Task Managers 122, 124, 126, 
128 and 130 track and monitor the data flow from a source 
5 computer software application to a destination computer 
software application. This data flow is collectively 
referred to herein as a "task" . Each of the Task Managers 
122, 124, 126, 128 and 130 is managed by a Key Master 106 
and 108, which launches, or terminates the Task Manager as 

10 needed. The Task Managers 122, 124, 126, 128 and 130 

receive message keys, described below, from the Agents 132, 
134, 136, 138 and 140 related to the task for which the 
Task Manager is responsible. For the embodiment shown in 
FIG. 1, the Task Manager 122 monitors a Task 162 associated 

15 with Agents 134, 136, 138 and 140. Similarly, the Task 

Manager 124 monitors a Task 164 associated with Agents 132, 
136 and 140. The Task Managers 122, 124, 126, 128 and 130 
also gather communication events, such as retry counts, 
timeouts, and downed connections. In addition, the Task 

20 Managers 122, 124, 126, 128 and 130 can also determine 

whether an alert situation has occurred, and to whom and 
how an alert should be delivered. The Task Managers 122, 
124, 126, 128 and 130 report alert situations and message 
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keys to the Gatekeeper 102, which then delivers the status 
information, alert situations and message keys to the 
appropriate Central Databases 112, 114 and 116. Depending 
on the specific organization of the Central Databases 112, 
5 114 and 116 are organized, information pertaining to a 
specific task can reside on one or more just some of the 
Central Databases 112, 114 and 116. Therefore, the 
Gatekeeper 102 may not deliver data to all the Central 
Databases 112, 114 and 116. 
10 In this embodiment, the Viewer 110 comprises a user 

interface for an operator to view the flow of 
configuration, monitoring and tracking data for various 
tasks to and from the Central Databases 112, 114 and 116 
for presentation via the Gatekeeper 102. More 
15 specifically, the Viewer 110 allows an operator to monitor 
the status of and issue commands through the Gatekeeper 102 
to change the online status and configuration of the 
Gatekeeper 102, the Key Masters 106 and 108, the Task 
Managers 122, 124, 126, 128 and 130, the Alert Dispatcher 
20 104, and the Agents 132, 134, 136, 138 and 140. In one 

example, the Viewer 110 connects to the Central Databases 
112, 114 and 116 via a Java Application Server based on the 
Java 2 Platform, Enterprise Edition (J2EE) . 
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In this embodiment, the Central Databases 112, 114 and 
116 contain status information, alerts and message keys, 
which originate from the Agents 132, 134, 136, 138 and 140 
and the Gatekeeper 102. In an embodiment 112, 114 and 116, 
5 the Central Databases 112, 114 and 116 comprise status 

information, alerts and message keys pertaining to specific 
tasks. In another embodiment, each of the Central Database 
112, 114 and 116 comprise differ classes of information. 
For example, the Central Database 112 can comprise status 

10 information, the Central Database 114 can comprise alerts, 
and the Central Database 116 can comprise message keys 
pertaining to specific tasks. In this example, for an 
alert situation, the Alert Dispatcher 104 need poll only 
the Central Database 114 which comprises alerts. 

15 The Agents 132, 134, 136, 138 and 140 receive messages 

and status information from the Sub-Agent 142, 144, 146, 
148 and 150 for which that Agent is responsible. In the 
embodiment shown in FIG. 1, the Agent 132 is responsible 
for the Sub-Agent 142, from which it receives messages and 

20 status information. Likewise, each of the Agents 134, 13 6, 
138 and 140 are responsible for and receive messages and 
status information from each of the Sub-Agents 144, 146, 
14 8 and 150, respectively. Upon receiving a message from a 
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Sub-Agent, the responsible Agent extracts a message key 
from the message. In one embodiment of the invention, a 
standard expressions are used to extract the message key. 
In this usage, a standard expression converts a message 
5 string into another string in a different language. The 

message key can incorporate information such as the type of 
message (e.g., medical record or patient), the Agent 
performing the extraction, and important message fields 
such as medical record number or patient ID. In one 
10 embodiment, a queue is used to buffer each connection 

between an Agent and a Task Manager. As shown in FIG. 1, a 
queue is used to buffer the connection between the Task 
Manager 122 and the Agent 136, and the Task Manager 124 and 
the Agent 140. This queue can reside either with the Agent 
15 or the Task Manager. As each Agent receives message keys 
or status information for a particular Task Manager, that 
message key or status information is placed into the queue. 
When the Task Manager is ready to process the information 
it removes it from the queue, which helps to optimize 
20 communication performance. 

It should be noted that the Task Managers need only to 
be connected to the Agents that monitor information 
relevant to that specific Task Manager's task. For 
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example, in the embodiment shown in FIG. 1, there is not a 
connection between the Agent 132 and the Task Manager 122 
because the Task 162 does not require information processed 
by the Agent 132. In addition, each Agent can service 
5 multiple Task Managers, such as shown in FIG. 1, where the 
Agent 136 is servicing both of the Task Managers 122 and 
124. In an embodiment, the Agents 132, 134, 136, 138 and 
14 0 can also decrypt known encrypted messages prior to key 
extraction. 

10 In this embodiment, the Sub-Agents 142, 144, 146, 148 

and 150 are deployed strategically close to the application 
machines 152, 154, 156, 158 and 160 that are operating 
applications to be monitored by the Data Tracking and 
Monitoring System 2. In this context, strategically close 

15 can mean either close in the physical sense (e.g., in the 
same room) or in a network sense (e.g., residing on the 
same subnetwork in the case of an Ethernet network) . 

The strategically close concept facilitates easier 
access to the data to be monitored. For example, as shown 

2 0 in the embodiment of FIG. 1, each of the Sub-Agents 142, 
144, 146, 14 8 and 150 are shown connected to each of the 
application machines 152, 154, 156, 158 and 160, 
respectively. In various embodiments, the Sub-Agents 142, 

19 
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144, 146, 148 and 150 assemble messages from a target 
source application machine 152, 154, 156, 158 and 160 by 
methods such as packet sniffing, which can be performed by 
tapping into an appropriate switch or router; file polling, 
5 which can be performed by a remote invocation to copy or 
view select files on a target application machine; 
Application Program Interface (API) collection of a 
specific message, which is a predefined API for extracting 
the desired message; or other protocols that have message 

10 collection features such as DECNET and SNA. Further, the 
Sub-Agents 142, 144, 146, 148 and 150 monitor the messages 
at the lowest common format such as, for example, 
Transmission Control Protocol/Internet Protocol (TCP/IP) , 
File Transfer Protocol/File Transfer Program (FTP) , or 

15 Systems Network Architecture (SNA) . Generally, the Sub- 
Agents 142, 144, 146, 148 and 150 remain non-intrusive with 
regard to process, disk space, memory and other resources 
on the target application machines 152, 154, 156, 158 and 
160. In addition, the Sub-Agents 142, 144, 146, 148 and 

20 150 are each configured with a message validator, which 

indicates whether a message is relevant to that Sub-Agent's 
operation. In one embodiment, this function is 
accomplished with a regular expression filter. If the 
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message matches a regular expression then it is classified 
as a pertinent message, and if the message fails to match a 
regular expression then it is classified as not pertinent 
to that Sub-Agent . As the Sub-Agents 142, 144, 146, 148 
5 and 150 collect pertinent messages, the messages are 

delivered to the responsible Agent. For example, the Sub- 
Agents 142, 144, 146, 148 and 150 deliver messages to the 
Agents 132, 134, 136, 138 and 140, respectively. 

The Data Tracking and Management System 2 as shown in 
10 FIG. 1 operates as follows. In this example, a Task 164 is 
being tracked as it is performed by computer application 
software on the application machines 152, 156 and 160. 
Sub-Agent 142, 146 and 150 monitor each of the application 
machines 152, 156 and 160, respectively, and retrieve all 
15 messages having content that matches a validator key for 
that specific Sub-Agent 142, 146 and 150. Those messages 
that match the validator key are then processed, and the 
message keys are extracted by the responsible Agent 132, 
136 and 14 0, respectively. After the message keys 
20 extracted, the messages are placed in queues for the 
responsible Task Manager, which in this case is Task 
Manager 124. When ready, the Task Manager 124 retrieves 
the message keys from the queue and delivers the messages 

21 
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to the Gatekeeper 102. Finally, the Gatekeeper 102 sends 
the data from the messages to the appropriate Central 
Databases 112, 114 and 116. This data can then be 
retrieved by the Gatekeeper 102 at a later time, and 
5 processed at the Viewer 110 for an operator to analyze. 

FIG. 2 shows a hardware configuration of the Data 
Tracking and Management System in an embodiment of the 
system. As shown in FIG. 2, a monitoring station 200 is 
connected to one or more central database servers 2 04. The 
10 central server 202 is also connected to the one or more 
central database servers 2 04, and to a network through 
switch 206. Switch 206 is connected to a central router 
208 for the network, which in turn is connected to other 
switches 210 and 212. In this embodiment, the higher level 
15 services are isolated by switch 206, thus providing an 
organizational advantage because all of the data is 
centralized in one location on the network. 

In an embodiment, each of the switches 210 and 212 
service a region such as a subnetwork on an Ethernet 
2 0 network. Each such region contains an Agent server 214 and 
224 and one or more computers using the applications to be 
monitored. In the embodiment shown in FIG. 2, the region 
serviced by switch 210 includes an Agent server 214 and 

22 
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four computers of various types, such as a laptop 216, 
desktop computers 218 and 220 and a workstation 222. 
Similarly, the region serviced by switch 212 includes an 
Agent server 224 and three computers of various types, such 
5 as a server 226, a desktop computer 228, and a 
microcomputer 230. 

In this embodiment, each of the Sub-Agents reside on 
the same computer as the responsible Agent on the Agent 
servers 214 and 224. Also, the Task Managers, the 
10 Gatekeeper, the Alert Dispatcher, the System Startup Module 
and Key Masters reside on a central server 2 02. The Viewer 
resides the monitoring station 200. Furthermore, switches 
210 and 212 are configured to allow the Sub -Agents on the 
Agent Servers 214 and 224 to monitor packets being 
15 transmitted through the switches 206 and 212. 

In one example of the data tracking and management 
system, the typical hardware requirements for the Key 
Master (s), the Gatekeeper, the Alert Dispatcher, and the 
Task Manager (s) include a computer with a Pentium 4 
20 processor operating at a 1 GHz speed, 512 Mb memory, 2x18 
Gb SCSI II Ultra Wide RAID hard-drive using a Linux 6.2 
operating system produced by Red Hat, Inc. In this 
example, the typical hardware requirements for the Agent (s) 
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include a computer with a Pentium 4 processor operating at 
a 1 GHz speed, 256 Mb memory, 18 Gb SCSI II Ultra Wide RAID 
hard-drive using a Linux 6.2 operating system. Further in 
this example, the typical hardware requirements for the 
5 Central Database (s) include a computer that uses a Solid 
Technologies Embedded Engine and using a Linux 6.2 
operat ing system . 

FIGS. 3-8 illustrate various message protocols between 
the various components of the system. While various 

10 messaging schemes and various message languages can be 
used, in the embodiment shown in FIGS. 3-8, messages 
between components conform to the Extended Markup Language 
(XML) . Furthermore, to identify components with multiple 
instances, an identification (ID) number is to assigned to 

15 each Task Manager, Key Master, Agent, and Sub -Agent . In 
addition, while many of the examples illustrate a single 
Task Manager, Key Master, Agent or Sub-Agent, the 
transaction is not restricted to a single component or a 
specific component in other embodiments. 

20 FIG. 3 shows a communications protocol of the Data 

Tracking and Management System in an embodiment of the 
invention. As shown in FIG. 3, for protocol 310, a Task 
Manager 300 configures an Agent 302 by issuing a message 
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312. The message 312 can comprise various configuration 
parameters for the Agent 302 , such as an IP address and a 
port number to perform sniffing operations and use the 
regular expression validator. For protocol 32 0, the Agent 
5 302 delivers a status code or a message key using a message 
322. Upon successful queuing of the information, the Task 
Manager 300 responds with an acknowledgement (ACK) 324. If 
the information fails to queue, the Task Manager 3 00 
responds with a negative acknowledgement (NACK) 326, at 
10 which point, the Agent 302 can retransmit the message 322. 

For protocol 330, the Task Manager 300 can shutdown 
the Agent 302 by issuing a message 332. Upon successful 
interpretation of the message 332, the Agent 302 responds 
with an ACK 334, otherwise the Agent 302 responds with a 
15 NACK 336. Upon receiving a NACK 336, the Task Manager 300 
can retry the shutdown procedure. 

FIG. 4 shows a communications protocol between a Task 
Manager and a Gatekeeper of the Data Tracking and 
Management System in an embodiment of the invention. For 
20 protocol 410, the Task Manager 400 notifies the Gatekeeper 
of the identity of its responsible Key Master, using a 
message 412. The message 412 comprises an identification 
(ID) number for the Task Manager 400 and an ID number of 
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its responsible Key Master. Upon successful interpretation 
of the message, the Gatekeeper 102 responds with an ACK 
414, otherwise the Gatekeeper 102 responds with a NACK 416. 
Upon receiving a NACK 416, the Task Manager 400 can 
5 retransmit the message 412. 

For protocol 42 0, the Task Manager 4 00 is configured 
by submitting a request message 422, which comprises the ID 
number of the Task Manager 400 making the request. The 
Gatekeeper 102 responds with a configuration message 424, 
10 which comprises various configuration parameters of the 

Task Manager 400, and any Agents or Sub -Agents it needs to 
communicate with along with the Agents and Sub-Agents 
configuration information. 

For protocol 430, the Task Manager 400 delivers status 
15 information or a message key to the Gatekeeper using a 
message 432. The message 432 comprises the status 
information or message key and can further comprise 
administrative information, such as the ID of the 
originating Agent, the ID of the Task Manager 400 and/or a 
20 time stamp. Upon successful processing of the message, the 
Gatekeeper 102 responds with an ACK 434, otherwise the 
Gatekeeper 102 responds with a NACK 436. Upon receiving a 
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NACK 436 , the Task Manager 400 can retransmit the message 
412. 

For protocol 440 , the Gatekeeper 102 identifies a Task 
Manager 4 00 to remove its queue when shutting down by 
5 issuing a message 442. Upon successful processing of the 
message 442, the Task Manager 400 responds with an ACK 444, 
otherwise the Task Manager 400 responds with a NACK 446. 
Upon receiving a NACK 446, the Gatekeeper 102 can 
retransmit message 442. 
10 FIG. 5 shows a communications protocol between a Key- 

Master and a Gatekeeper of the Data Tracking and Management 
System in an embodiment of the invention. For protocol 
510, a Key Master 500 notifies the Gatekeeper 102 that it 
is ready to start using a message 512. The Gatekeeper 102 
15 responds with a message 514 comprising the ID numbers of 
the Task Manager 4 00 that is assigned to the Key Master 
500. Upon receiving the response, the Key Master 500 
relaunches any Task Manager 400 that is not online. 

For protocol 52 0, the Gatekeeper 102 instructs the Key 
20 Master 500 to shutdown the Task Manager 4 00 by issuing a 
message 522, which comprises the ID number of the Task 
Manager 400 to be shutdown. Upon successful processing of 
the message 522, the Key Master 500 issues a shutdown 
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request to the Task Manager 4 00 and responds with a message 
524, which comprises the ID numbers and responses of the 
Task Manager 400 to the requests of the Key Master 500. 
Upon receipt of the message 524 , the Gatekeeper 102 can 
5 elect to request a shutdown of the unresponsive Task 

Manager 400. For example, if the message 522 instructs the 
Key Master 500 to shutdown Task Manager 400 with ID 1,2, and 
4, the Task Manager 400 with ID 1 and 2 may shutdown, but 
the Task Manager 400 with ID 4 may have responded to the 

10 Key Master 500 with a NACK. The response message 524 would 
comprise the following associated information: ID 1 reports 
ACK, ID 2 reports ACK, ID 4 reports NACK. Upon receipt of 
the message 524, the Gatekeeper 102 can transmit another 
message 522 with a request to shut down the Task Manager 

15 400 with ID 4 . 

For protocol 530, the Gatekeeper 102 requests the Key 
Master 500 shutdown using a message 532, which can comprise 
the ID number of the Key Master 500 to be shutdown. Upon 
successful processing of the message, the Key Master 500 

2 0 respond with an ACK 534 just prior to shutdown. If 

unsuccessful, the Key Master 500 responds with a NACK 536, 
at which point the Gatekeeper 102 can repeat the shutdown 
process . 
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FIG. 6 shows a communications protocol between an 
Alert Dispatcher and a Gatekeeper of the Data Tracking and 
Management System in an embodiment of the invention. For 
protocol 610, the Alert Dispatcher 104 registers with the 
5 Gatekeeper 102 using a message 612. Upon successful 

processing of the message 612, the Gatekeeper 102 responds 
with an ACK 614 , otherwise the Gatekeeper 102 responds with 
a NACK 616. If the NACK 616 is sent, the Alert Dispatcher 
104 can elect to retransmit message 612. The ACK 614 can 
10 further comprise Alert Dispatcher configuration 

information, such as the no alert interval, which is the 
interval of time during which any alert received should be 
deferred until after the interval expires. 

For Protocol 620, the Gatekeeper 102 sends status 
15 messages to the Alert Dispatcher 104 using a message 622. 
Upon successful processing of the message, the Alert 
Dispatcher 104 responds with an ACK 624, otherwise a NACK 
626 is returned. Upon receipt of the ACK 624, the 
Gatekeeper 102 stores this event in an alert history log. 
20 If a NACK 626 is received, the Gatekeeper 102 can 
retransmit the status message 622. 
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For protocol 630, the Gatekeeper 102 requests the 
Alert Dispatcher 104 to shutdown, using a message 632. Upon 
successful processing of the message, the Alert Dispatcher 
104 responds with an ACK 634. If unsuccessful, the Alert 
5 Dispatcher 104 responds with a NACK 63 6, at which the 
Gatekeeper 102 can repeat the shutdown process. 

For protocol 640, the Gatekeeper 102 reconfigures the 
Alert Dispatcher 104 using a message 642, which comprises 
configuration parameters for the Alert Dispatcher 104, such 

10 as a no alert interval. Upon successful processing of the 

message, the Alert Dispatcher 104 responds with an ACK 644. 
If unsuccessful, the Alert Dispatcher 104 responds with a 
NACK 646, at which time the Gatekeeper 102 can retransmit 
the message 642 . 

15 FIG. 7 shows a communications protocol between an 

Agent and a Sub-Agent of the Data Tracking and Management 
System in an embodiment of the invention. For protocol 
710, the Agent 700 configures a Sub-Agent 702 using a 
message 712, which comprises a configuration information 

20 for the Sub-Agent 702, such as IP address, ports to sniff 
packets, and/ or login information used to poll log files. 
Upon successful processing of the message, the Sub- Agent 
702 responds with an ACK 714. If unsuccessful, the Sub- 
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Agent 702 responds with a NACK 716, which can further 
comprise a failure reason, at which the Agent 700 can 
retransmit message 712. 

For protocol 720, the Sub-Agent 702 can submit to its 
5 responsible Agent 700 a message 722 that matches the 
validator of the Sub-Agent 702. 

FIG. 8 shows a diagram illustrating a shutdown 
procedure for a Task Manager of the Data Tracking and 
Management System in an embodiment of the invention. As 

10 shown in FIG. 8, the Viewer 110 issues a command message 

810 to the Gatekeeper 102 to shutdown Task Manager 400. In 
accordance with the protocol 52 0, the Gatekeeper 102 issues 
the message 522 to the responsible Key Master 802. The Key 
Master 802 then attempts to shutdown the Task Manager 400. 

15 The success of this action is reported back to the 

Gatekeeper 102 in the message 524, which comprises the ID 
number of the Task Manager 4 00 and the ID number of its 
responsible Key Manager 8 02. 

FIG. 9 shows a diagram illustrating a shutdown 

2 0 procedure for a plurality of Task Managers of the data 

tracking and management system. In the embodiment shown in 
FIG. 9, a Key Master 900 is responsible for the Task 
Manager 400 of ID 1 and ID 2 and the Key Master 902 is 
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responsible for the Task Manager 400 of ID 3 and ID 4 . In 
this embodiment, the Viewer 110 issues requests to shutdown 
the Task Manager 400 of ID 1, ID 2 , ID 3 and ID 4 with 
messages 810a, 810b, 810c and 810d. The messages 810a, 
5 810b, 810c and 810d have the same types of fields as the 
message 810 mentioned above, but differ in their values. 
The Gatekeeper 102 accumulates these requests and using 
protocol 52 0 submits two shutdown request messages 522a and 
522b for the Task Manager 400 to the Key Master 900 and the 

10 Key Master 902, respectively. In this example, if the Key 
Master 900 has successfully shutdown the Task Manager 400 
of ID 1 and ID 2, then the return message 524a comprises an 
ACK for ID 1 and ID 2. Likewise, if the Key Master 902 has 
successfully shutdown the Task Manager 400 of ID 3 but not 

15 of ID 4, then the return message 524b comprises an ACK for 
ID 3 but a NACK for ID 4. Upon receiving the message 524b, 
the Gatekeeper 102 can again attempt to shutdown the Task 
Manager 4 00 of ID 4 by sending a request message 522c to 
the Key Master 902. If the Key Master 902 is successful in 

2 0 shutting down the Task Manager 400 of ID 4, then the return 
message 542c comprises an ACK for ID 4. 
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FIG. 10 shows a diagram illustrating a shutdown 
procedure for a Key Master of the Data Tracking and 
Management System in an embodiment of the invention. As 
shown in FIG. 10, the Viewer 110 sends message 1002 to the 
5 Gatekeeper 102 to request the shutdown of a Key Master 

1000. The remaining transaction follows the protocol 530 
as described above. 

FIG. 11 shows a diagram illustrating a shutdown 
procedure for a Gatekeeper of the Data Tracking and 
10 Management System in an embodiment of the invention. In 
the embodiment shown in FIG. 11, the Viewer 110 requests 
the shutdown by issuing a command message 1100 to the 
Gatekeeper 102 . 

FIG. 12 shows a diagram illustrating a shutdown 
15 procedure for an Alert Dispatcher of the Data Tracking and 
Management System in an embodiment of the invention. In 
the embodiment shown in FIG. 12 , the Viewer 110 sends a 
request message 1200 to the Gatekeeper 102. The remainder 
of the transaction then follows the protocol 630 as 
20 described above. 

The systems and methods of the present invention may 
be embodied in other specific forms without departing from 
the teachings or essential characteristics of the 
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invention. The described embodiments are therefore to be 
considered in all respects as illustrative and not 
restrictive, the scope of the invention being indicated by 
the appended claims rather than by the foregoing 
5 description, and all changes which come within the meaning 
and range of equivalency of the claims are therefore to be 
embraced therein. 



